This is a minor thing, and perhaps you don't want to do this, but I thought I would mention anyway - would it be worth adding a section looking a the bigger picture, and whether how far we should be trying to go to match SAS rounding? I'm thinking about the fact that if we are trying to move to R-based submissions, then some of this stuff should in a way be expected and accepted. My idea comes from this comment by @rossfarrugia .

when moving from SAS to R submission, what kind of discrepancy are expected/accepted for rounding?

to add context to my comment before... when using same language for double programming QC often teams would strive for a 100% perfect comparison match, whereas when working in a multi-lingual world maybe it's ok to not perfectly match if differences can be explained in audit-ready QC evidence to explain differences are down to the use of different languages. e.g. a % in first line output with R is 1% and in QC with SAS it is 2%, and upon inspection the QC'er sees that the actual value is 1.5% rounded, hence just add a comment in QC evidence to explain such differences are considered acceptable.

e.g. a % in first line output with R is 1% and in QC with SAS it is 2%, and upon inspection the QC'er sees that the actual value is 1.5% rounded, hence just add a comment in QC evidence to explain such differences are considered acceptable.

This discrepancy is not caused by SAS/R, but by different rounding approaches, which I think should be based on the study SAP instead of the software. Should the rounding method be clarified first, then choose the corresponding functions in SAS/R?

I'd doubt most SAPs would go into such detail as nobody really ever questioned rounding approaches when we only used single language. It's a fair point though. I feel like a closing note such as "Note: with the differences in default behaviour across languages, you could consider your QC strategy and whether an acceptable level of fuzz in the electronic comparisons could be allowed for cases such as rounding when making comparisons between 2 codes written in different languages as long as this is documented. Alternatively you could document the exact rounding approach to be used in the SAP and then match this regardless of programming language used."

Good summary, I will add it next week after the holiday.
The reason I prefer to align with the rounding method during QC is that when we accept the difference, it's easy to overlook the differences caused by other reasons., e.g., RConsortium/submissions-pilot3-adam#99

Thanks @rossfarrugia @clarkliming for your comments and discussion!

personally, I don't think we should do this. this will change a lot of behaviors, like ut_round1(2436.84499999999999, 2) gives 2436.85 while round(2436.84499999999999, 2) gives 2436.84 (which is correct)

@clarkliming Thanks for the review! your example is a similar case to the one mentioned above: a <- 1.5 - 0.5*sqrt(.Machine$double.eps)

The reason for this behavior is that 2436.845 - 2436.84499999999999 is less than sqrt(.Machine$double.eps), the adjustment in the function is not big enough to round it up. When we encounter this situation, maybe we could handle it by the following options -

1. accept this value and explain: 2436.845 and 2436.84499999999999 are nearly equal by using all.equal() function from base R with default tolerance value (default tolerance = sqrt(.Machine$double.eps)

   • the output from SAS round(2436.84499999999999, 0.01) is also 2436.85

2. choose a smaller value than sqrt(.Machine$double.eps) or remove it to adjust this function

How would you do "round half up" in R if we don't choose those functions (ut_round1, janitor::round_half_up, ...)?

I assume this function will be used deeply inside other functions and large-scale used, so controlling the tolerance manually is not likely(which means that users can only apply one tolerance to all the numeric results obtained).

I will split your question into two: one is how do we deal with round half up, the other is how do we deal with rounding error.

My response to these two questions is the same: no action is needed.

For question 1, R is following IEEE 754, with default bankers rounding. What SAS provided seems reasonable, however, R is not wrong. This is just a different method. R does not need to copy SAS.

For question 2, about the accuracy loss in computation, I will also do nothing. This is an issue by design, and not possible to perfectly solve at the moment.

Both issues won't affect the interpretation of the result

So for me, introducing the fact that R and SAS are different in rounding should be sufficient.

Come back to the issue. The function ut_round1 tries to solve the rounding error arising from the design, but it did not. So it is important to also mention this point. (also, this issue is not possible to solve in the current design, this fix only fixes one part of the issue)

I'm not trying to claim that base R's round function is wrong or we should strictly mimic SAS's behavior, but to provide round half up options in R. Similar as the intention of providing rounding option in Tplyr, offering users more flexibility - there may be contexts where 'round half up' is required.

What do you think of using the following examples to highlight those round_half_up functions do not offer the same level of precision and accuracy as the base R round function?
Please feel free to update this post directly, or let me know how to clarify this point :)

> a <- 1.5 - 0.5*sqrt(.Machine$double.eps)
> b <- 1.5 - 0.5*.Machine$double.eps
> janitor::round_half_up(a)
[1] 2
> janitor::round_half_up(b)
[1] 2
> round(a)
[1] 1
# base round reaches the precision limit:
> round(b)
[1] 2